home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2345 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.5 KB  |  71 lines
  1. Path: locutus.rchland.ibm.com!usenet
  2. From: pstaite@vnet.ibm.com
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Q:order of evaluation
  5. Date: 16 Jan 1996 22:10:09 GMT
  6. Organization: IBM OS/2 Device Driver Development  Rochester, MN
  7. Message-ID: <4dh7o1$bfi@locutus.rchland.ibm.com>
  8. References: <4dfhlu$a33$1@mhafn.production.compuserve.com>
  9. Reply-To: pstaite@vnet.ibm.com
  10. NNTP-Posting-Host: warpone.rchland.ibm.com
  11. X-Newsreader: IBM NewsReader/2 v1.2
  12.  
  13. In <4dfhlu$a33$1@mhafn.production.compuserve.com>, Holger Maier <100336.3326@CompuServe.COM> writes:
  14. >Consider
  15. >#include <iostream>
  16. >int main() {
  17. >  int i=1;int j=i+(i+=1);
  18. >  cout<<i<<','<<j<<'\n';
  19. >  return 0;
  20. >}
  21. >on my compiler this produces 2,4
  22. >Looked up the ARM:
  23. >5: .. The order of evaluation of subexpressions is determined by the
  24. >precedence and grouping of operators.
  25. >5.7: The additive operators + and - group left to right.
  26. >So, j should be assigned 3 ??
  27. >Now the question to you C++ gurus out there on the nets:
  28. >Is it really a compiler bug or is it just me misinterpreting the 
  29. >ARM?
  30. >BTW: I know we should not code like that...
  31.  
  32. Gads, not this thread again...  Note in the ARM (hopefully somewhere 
  33. close to where you found that part) it states something to the effect:
  34.  
  35. "Order of evaluation of operands is undefined."
  36.  
  37. Thus, while precedence and grouping solve the algebra of the operators,
  38. the evaluation of the variables and subexpressions that make up the
  39. operands is undefined.  If you had:
  40.  
  41. a = b + c + d;
  42.  
  43. The compiler will evaluate/perform the + subexpression/operation between
  44. b and c first, then evaluate/perform the + subexpression/operation
  45. between the intermediate result and d.  However, it may *evaluate* d
  46. first and put it in a register somewhere.
  47.  
  48. Even in the case of:
  49.  
  50. a = b + c * d;
  51.  
  52. It must perform the multiplication before the addition.  However, it can
  53. evaluate b first, it just cannot perform the addition until the 
  54. multiplication is done.
  55.  
  56. Therefore, getting back to your code, a compiler is free to load the
  57. value of i in a register, then evaluate (i+=1) then add the result to 
  58. the register.  This would produce an answer of 3.  OTOH, the compiler
  59. could just as easily evaluate the () operand of + first, storing 2 in i,
  60. then add that to i and assign to j.  This would produce 4.
  61.  
  62. In short, you've modified an object (variable i) twice with no
  63. intervening sequence point.  Therefore the result is undefined, it could
  64. assign 87 to j and that would be just fine (unexpected, but still 
  65. legal ;-), undefined means anything goes.
  66.  
  67.  
  68. Phil Staite, team OS/2
  69. internet: pstaite@vnet.ibm.com  internal: pstaite@rchland
  70.  
  71.